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URI Scheme for Java(tm) Message Service 1.0 
Abstract 


This document defines the format of Uniform Resource Identifiers 
(URIS) as defined in RFC 3986, for designating connections and 
destination addresses used in the Java(tm) Messaging Service (JMS). 
It was originally designed for particular uses, but applies generally 
wherever a JMS URI is needed to describe the connection to a JMS 
provider, and access to a JMS Destination. The syntax of this JMS 
URI is not compatible with previously existing, but unregistered, 


"jms" URI schemes. However, the expressiveness of the scheme 
described herein should satisfy the requirements of all existing 
circumstances. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6167. 
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(http://trustee.ietf.org/license-info) in effect on the date of 
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carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


This document may contain material from IETF Documents or IETF 
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10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
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it for publication as an RFC or to translate it into languages other 
than English. 


Phillips, et al. Informational [Page 2] 


RFC 6167 jms" URI Scheme April 2011 


Table 


Wh 


oo xN o0 


of Contents 


Ener rodut Oom ses eenaa e E E Se sacle oS e E Sree: E E eee Ge E ES 3 
I Lo Reguirements- Notation torest eA eed PR a cok Bik a a E aA 4 
URP “SCHEMES Namet ginu wos staat see bey e E een dares a cam al pene bien wna car EA rE E E a 5 
Syntax Of @ JMS URD sein e a siete ie, che Spo S etn N ve av epinie ve, oh dee dae Sig aver eines 5 
URI Scheme Semantis: ssaa Kaeo ar ees lela ios Se athe es ores Sete shale Sores oO eh dees eo 5 
Joto Shared (Parameters: Wht ak sath A ee ai hk RA she GNA et a See, Shik a ce oe 6 
Fe Dire STON Vie BATU 9 se. took co ng wiser ox at fe cos fen Seat ia po AE ation nie dente ca hsmetlepec EEEE 7 
4.3. Vendor Destination Names -- Variants "queue" and "topic" ..11 
44-2 Custom: Parameters: orig cts sce ibe lecde Ace we eg Gaede re Se ore Sei eed eee ere 12 
Encoding: Consideration se sne eee eres SE: wae Soe See eed Hew ee ee 13 
Applications/Protocols That Use the JMS URI .................... 13 
Interoperability Considerations: socscsserer e eg e en ee EE el eee ees 13 
Secubity Consideratións osiad ropne resor Se ee EES T Cae SSR eee 14 
8.12 Reliability and -COnSiTStenGy” s ssee siete See eee oe Le ed aeeai e Sets 14 
8:2. MalLaciOus CONSEEUCETON: foe and She E e he EnA gene gt E were Mis cau eee 14 
83 Back-End- Transcoding .aisse-ctltets pcartee Gaels ate e-ette eine wee Seve ane wie 15 
84s. SemantacrAteacks:< aaya n a 4 a a a a a a Seis ee A alte 15 
8-5 Other Secüřtity Concerns oee teaei e r A Entel E ay piesa oe 16 
TANAY GONSPASTARLO MS! e aieri naar itor, a erie tans eA re ate a, chdus nA a aha aires 16 
9.17 URL “SCHEME Registration reee eaa ae is erecta ee wee ee eee eee 16 
9.22.9" jms T URL Scheme Registries eses siessen es ae oe SE See ES ES 17 
CONE ELDUT OTS: gravel ceva sone here ene eS Bee: Bal cele eds ogee BB AA a Sole ood, ba ee 18 
ACKMOWLEAGEMENES scsi cists Oakes E ese T dice ate a dle! oleae are a 19 
References Sey area ie Seaesd Seed. Greed wae Sead aes Seer Shae Sead Sd) eae gears Sia he Seeds 20 
12-1 Normative References’ iie deterse ie ah eet he eek eed ee bee oe 20 
12.2: Informative REFSrENCSS: sis ebe ie Suche eee de leve lores Gl ogee dele e er ee8 21 


1. Introduction 


The "jms" URI scheme is used to designate a javax.jms.Destination 
object and an associated javax.jms.ConnectionFactory object [JMS], 
and, optionally, to provide additional information concerning the way 
that the Destination object is to be used. Probably the most common, 
and certainly the most compatible, way in Java to retrieve such 
Destinations is via Java Naming and Directory Information (JNDI) 
[JNDI] methods. So as to extend compatibility to existing vendor 
mechanisms beyond JNDI lookup, the JMS URI syntax allows variants on 
the core syntax. The variant exists as an explicit part of the 
syntax so that tools that are otherwise unfamiliar with the variant 
can recognize the presence of a URI with an alternate interpretation. 
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In its simplest and most interoperable form, this URI scheme starts 
with "Jjms:jndi:" plus a JNDI name for a Destination. Since 
interaction with some resources might require JNDI contextual 
information or JMS header fields and properties to be specified as 
well, the "Jjndi" variant of the "jms" URI scheme includes support for 
supplying this additional JNDI information as query parameters. 


While the "jndi" variant provides compatibility, vendors can define 
additional variants. This specification defines three variants: 
"jndi", "queue", and "topic". Vendors defining additional variants 
are strongly encouraged to register them with IANA as documented in 
Section 9.2.1. 


While the "jms" URI scheme allows the location of network resources, 
it does not map to a single underlying protocol, unlike most other 
URI schemes that do so. Instead, it achieves interoperability 
through the use of a common Java-based API [JAVA] for messaging. 
Because of this, interoperability is dependent upon the 
implementation of the API and its capabilities; two implementations 
of JMS might or might not interoperate in practice. Furthermore, it 
might be impractical to use JMS URIs in non-Java environments. 


As a consequence of building upon an API, rather than a protocol, the 
utility of a JMS URI depends on the context in which it is used. 

That context includes agreement on the same JMS provider or 
underlying protocol; agreement on how to look up endpoints (JNDI); 
and, when using serialized Java object messages, sufficiently similar 
Java Class environments that serialized objects can be appropriately 
read and written. Users of this scheme need to establish the 
necessary shared-context parts as just enumerated -- a context that 
can span the globe, or merely a small local network. With that 
shared context, this URI scheme enables endpoint identification ina 
uniform way, and the means to connect to those endpoints. 


1.1. Requirements Notation 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


All syntax descriptions use the ABNF specified by [RFC5234], 
"Augmented BNF for Syntax Specifications: ABNF". 


Note that some examples in this document wrap long JMS URIs for 
readability. The line breaks are not part of the actual URIs. 
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2. URI Scheme Name 
The name of the URI scheme is "jms". 
3. Syntax of a JMS URI 
The following ABNF describes the "jms" scheme URI syntax: 


jms-uri = "jms:" jms-variant ":" jms-dest 
[ "2?" param *( "&" param ) ] 


jms-variant = segment-nz-nc 

jms-dest = segment-nz ; specific meaning per variant 
param = param-name "=" param-value 

param-name = 1* (unreserved / pct-encoded) 
param-value = *(unreserved / pct-encoded) 


segment-nz-ne = <as defined in RFC 3986> 


path-rootless <as defined in RFC 3986> 


unreserved = <as defined in RFC 3986> 
pct-encoded = <as defined in RFC 3986> 


The URIs are percent-encoded UTF-8 [RFC3629]. Please see Section 5 
of this document for encoding considerations. 


4. URI Scheme Semantics 


JMS URIs are used to locate JMS [JMS] Destination resources and do 
not specify actions to be taken on those resources. Operations 
available on JMS Destinations are fully and normatively defined by 
the JMS specification and as such are out of scope for this URI 
specification. 


The required portions of the syntax include the terminal of "jms" for 
the URI scheme name; the <jms-variant> element to indicate the 
variant of the scheme; and the <jms-dest> element, which identifies 


the Destination based on the chosen variant. For the <jms-variant> 
element, this document defines three values: "jndi", "queue", and 
"topic". All the terminals resulting from <jms-variant> and 


<jms-dest> production rules are case-sensitive. 


Phillips, et al. Informational [Page 5] 


RFC 6167 jms" URI Scheme April 2011 


Parameters further refine how to locate and use the Destination. The 
parameter names and values are case-sensitive. They can occur in any 
order, and each parameter name SHOULD NOT appear more than once. In 
the event that a parameter appears multiple times, all but the last 
instance of the parameter MUST be ignored. For comparison purposes, 
the absence of a parameter does not mean the same thing as a URI with 
a parameter set to a default value, due to the potential variation in 
default values as determined by the context of a specific use. 


Each variant can have query parameters specific to that variation. 
All such variant-specific parameters SHOULD use the name of the 
variant as the prefix to the parameters. For example, a vendor- 
specific variant of "vnd.example.ex" might also define a parameter 
with a name like "vnd.example.exParameter". Parameters that apply 
across multiple variants -- perhaps because they are generally 
applicable, such as JMS settings -- MUST NOT have a name that starts 
with the name of any known variant. This pattern enables tools that 
are otherwise unfamiliar with a particular variant to distinguish 
those parameters that are specific to a variant from those that are 
more generally applicable. 


Examples of the URI scheme include: 


jms: jndi:SomeJndiNameForDestination? 
jndiInitialContextFactory= 
com.example.jndi.JndiFactoryépriority=3 


jms : queue: ExampleQueueName?timeToLive=1000 
4.1. Shared Parameters 


In addition to the required particles, the "jms" URI scheme supports 
the following shared parameters, which are available to all variants. 
These parameters correspond to headers and properties on the JMS 
Messages to be sent. For the parameters deliveryMode, timeToLive, 
and priority, the default values might be specified in the context of 
a specific use, for example by environment variables, or in the 
configuration of a particular network application. JMS also defines 
default values for these properties. The context default is hereby 
defined as the default value in the context of a specific use, or the 
JMS default for a particular property if the context does not define 
a default. 
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4.1.1. deliveryMode 


Indicates whether the request message is persistent or not. This 
property corresponds to the JMS message header field 
"JMSDeliveryMode" defined in Section 3.4.2 of the JMS 1.1 
specification [JMS]. The value of this parameter MUST be 
"PERSISTENT" or "NON_PERSISTENT". If this parameter is not 
specified, then the context default MUST be used. 


4.1.2. timeToLive 


The lifetime, in milliseconds, of the request message, specified as a 
decimal number. This property corresponds to the JMS Time-To-Live 
value defined in Section 4.8 of the JMS 1.1 specification. If this 
parameter is not specified, then the context default MUST be used. 


4.1.3. priority 


The JMS priority associated with the request message. As per 
Section 3.4.10 of the JMS 1.1 specification, this MUST be a value 
between 0 and 9 inclusive, specified as a decimal number. This 
corresponds to the JMS message header field "JMSPriority". If this 
parameter is not specified, then the context default MUST be used. 


4.1.4. replyToName 


This property corresponds to the JMS message header field 
"JMSReplyTo" defined in Section 3.4.6 of the JMS 1.1 specification. 
As interpreted by the particular variant, this property value 
specifies the JMS Destination object to which a response message 
ought to be sent. 


4.2. “Jjndi" Variant 


The "Jjndi" variant implies the use of JNDI for discovering the 
Destination object. When this is specified as the variant, the 
<jms-dest> portion of the syntax is the name for JNDI lookup 
purposes. Additional JNDI-specific parameters can be specified. The 
JNDI-specific parameters SHOULD only be processed when the URI 
variant is "jndi". 


4.2.1. INDI Parameters 
4.2.1.1. JjndiConnectionFactoryName 
Specifies the JNDI name of the Java class (see Section 3.8, 


"Identifiers", of [JLS] for the specification of a legal Java class 
name) providing the connection factory. 
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4.2.1.2. JjndiInitialContextFactory 


Specifies the fully qualified Java class name of the 
"InitialContextFactory" implementation class to use. 


4.2.1.3. jndiURL 


Specifies the JNDI provider URL, in a form consistent with 
javax.naming.spi.NamingManager.getURLContext (String scheme, Hashtable 
environment) as defined in the JNDI specification [JNDI]. 


4.2.1.4. Additional JNDI Parameters 


4 


2 


It is possible that connecting to a JNDI provider requires additional 
parameters. These parameters can be passed in as custom parameters 
(see Section 4.4). To identify a custom parameter as JNDI specific, 
the parameter name needs to start with the prefix "jndi-". 


For example, if the JNDI provider requires a parameter named 
"com.example.jndi.someParameter", you can supply the parameter in the 
URI as: jndi-com.example.jndi.someParameter=someValue 


-2. Example of Performing a JNDI Lookup 


To perform a lookup based on a "Jjndi" variant URI using Java APIs, an 
application might start by creating a JNDI InitialContext object. 

The InitialContext object can then be used to look up the JMS 
ConnectionFactory object (using the "jndiConnectionFactoryName" URI 
parameter), the target JMS Destination object (using the <jms-dest> 
portion of the JMS URI), and the "replyToName" JMS Destination object 
(if the "replyToName" parameter is specified on the URI). The 
application creates the InitialContext object by first setting up two 
properties: "Context.INITIAL_CONTEXT_FACTORY", with the value of the 
jndilInitialContextFactory JMS URI parameter; and 
"Context.PROVIDER_URL", with the value of the jndiURL URI parameter; 
and then passing the two properties to the InitialContext 
constructor. 


To locate a connection factory or Destination object, the application 
passes the name of the object into the InitialContext.lookup () 
method. 
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For example, the JMS URI... 


jms: jndi:REQ_QUEUE 
? jndiURL=file:/C:/JMSAdmin 
&jndiInitialContextFactory 
=com.sun. jndi.fscontext .RefFSContextFactory 
& JjndiConnectionFactoryName=CONNFACT 
&replyToName=RESP_QUEUE 


...-would be used by the following (non-normative) code sample to 
locate and retrieve a JMS ConnectionFactory called "CONNFACT", and 
JMS Destinations called "REQ QUEUE" and "RESP QUEUE", from a file- 
system JNDI context called "c:/JMSAdmin". 


/ 

Preconditions on URI: 

—- portion <jms-dest> has been parsed into variable "jms_dest" 

- parameters "jndiConnectionFactoryName", 
"J3ndiInitialContextFactory", "“replyToName", and "jndiURL" have 
been parsed into variables of the same name. 


+ + F F +*+ F 


/ 

Hashtable environment = new Hashtable(); 

environment.put (Context .INITIAL_CONTEXT_FACTORY, 
jndiInitialContextFactory) ; 

environment .put (Context .PROVIDER_URL, jndiURL) ; 


/* 
* Create File-System Initial Context 
* 
Context ctx = new InitialContext (environment) ; 
/* 


* Now get the JMS ConnectionFactory and Destination. These will 
* be used later on in the application to create the JMS 
* Connection and send/receive messages. 
* if 
ConnectionFactory jmsConnFact = (ConnectionFactory) 
ctx. lookup (jndiConnectionFactoryName) ; 
Destination requestDest = (Destination) ctx.lookup(jms_dest) ; 
Destination replyDest = (Destination) ctx.lookup(replyToName) ; 


The ConnectionFactory is used to create a Connection, which itself is 
used to create a Session. The Session can then be used to create the 
MessageProducer, which sends messages to the target Destination; and 
the MessageConsumer, which receives messages from the replyToName 
Destination (as shown in the following code extract). 
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* Create a producer to send a message to the request Destination 
* that was specified in the URI, then create the message, setting 
* the replyToName Destination in the message to the one specified 
* in the URI, and send it. 
af 
MessageProducer producer = sess.createProducer (requestDest) ; 
BytesMessage reqMsg = sess.createBytesMessage(); 
reqMsg.setJUMSReplyTo(replyDest) ; 
producer.send(reqMsqg) ; 
/* 
* Create a consumer to get a message from the replyToName 
* Destination using a selector to get the specific response to 


* this request. The responder sets the correlation ID of the 
* response to the message ID of the request message. 
*/ 
MessageConsumer consumer = sess.createConsumer (replyDest, 
"JMSCorrelationID = ’" + reqMsg.getJUMSMessageID() + "’"); 
Message respMsg = (Message) consumer.receive (300000) ; 


4.2.2.1. Performing a JNDI Lookup with Custom Parameters 


Any parameters with a prefix of "jndi-" MUST be used to set custom 
properties when establishing a connection to the JNDI provider. The 
name of the custom property is derived by removing the "jndi-" prefix 
from the URI parameter name, and the value of the property is the 
value of the parameter. 


For example, the JMS URI... 


jms: jndi:REQ_QUEUE 
?jndiURL=file:/C:/JMSAdmin 
&jndiInitialContextFactory 
=com.sun. jndi.fscontext .RefFSContextFactory 
& jndiConnectionFactoryName=CONNFACT 
& jndi-com.example.jndi.someParameter=someValue 


..-instructs the consumer to use the following properties to connect 
to the JNDI provider: 


java.naming.provider.url=file:/C:/JMSAdmin 

java.naming.factory.initial= 
com.sun.jndi.fscontext.RefFSContextFactory 

com.example. jndi.someParameter=someValue 
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4.3. Vendor Destination Names -- Variants "queue" and "topic" 


The JMS Session object provides a means to directly access Queues and 


Topics. Specifically, it has the methods Session.createQueue (String 
name) and Session.createTopic(String name). These methods can be 
used to "create" the Java representation of an existing JMS Topic or 
Queue. 


Since the Session interface requires external knowledge about whether 
a given name relates to a Queue or Topic, rather than introducing one 
new variant, this section defines two variants. A JMS URI can 
indicate which of these methods to use by specifying the appropriate 
variant -- either "queue" or "topic". For example: 


jms : queue: ExampleQueueName 

to identify a JMS Queue Destination, and 
jms: topic:ExampleTopicName 

to identify a JMS Topic Destination. 


JMS only specifies one way to obtain the names used by these APIs. 
With a JMS Queue or Topic available, an implementation can call 
Queue.getQueueName() or Topic.getTopicName(), respectively, both of 
which return a String object. To create a correct corresponding URI, 
the resulting string MUST use standard URI escape mechanisms so that 
the resulting characters conform to the production <jms-dest>. 


4.3.1. Treatment of replyToName Parameter 


When used with the "queue" and "topic" variants, the replyToName 
parameter, specified in Section 4.1.4, always refers to a name of a 
JMS Queue to look up via the Session.createQueue() method, or its 
equivalent. For either variant, if a JMS Topic is instead required 
as a response Destination, a JMS URI can employ the 
"topicReplyToName" parameter. This parameter defines a name to look 
up with the Session.createTopic() method, or its equivalent. 


A JMS URI MUST NOT specify both a "topicReplyToName" and a 
"replyToName" parameter. 


4.3.2. Obtaining a Session via JNDI 


Using the Session.createQueue() and Session.createTopic() methods 
assumes that a client program has already obtained a Session object. 
Where does that Session object come from -- how does a client get it? 


One way to get a Session is simply to access vendor-specific APIs. 
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4. 


23. 


4. 


Another way to get a Session object is to simply revert to using 
JNDI. That is, if a Session is not available to the client from some 
other context, the "queue" and "topic" variants MAY reuse the URL 
parameters specified in Section 4.2.1, "JNDI Parameters". Via JNDI, 
those parameters will identify a ConnectionFactory, which can then be 
used to obtain a Session object. 


Combining the "queue" and "topic" variants with JNDI lookup for an 
implementation of ConnectionFactory raises an important consideration 
for JMS URI clients. Once clients employ JNDI for one part of 
discovering a Destination, they almost certainly could use a vendor- 
neutral JNDI lookup for a Destination object itself, rather than 
using vendor-specific means. As a result, clients need to carefully 
consider whether it makes sense to use JNDI for one part of this 
problem, without using it for the other. 


3. Limitations of "queue" and "topic" 


The JMS specification clearly identifies the two methods on the 
Session interface as returning vendor-specific names for 
Destinations. Consequently, users of the "jms" URI scheme ought to 
carefully consider when these two variants might be employed. If 
users plan on switching between JMS vendors, they might also need to 
plan on regenerating resources that contain URIs in this vendor- 
specific form. 


A JMS vendor can provide alternate ways to obtain the names that can 
be passed to Session.createQueue() and Session.createTopic(). When 
using names derived from those alternate means, users of this URI 
specification are encouraged to verify that the obtained names work 
as expected in all circumstances. 


Custom Parameters 


The set of parameters is extensible. Any other vendor- or 
application-defined parameter can be supplied, in the URI, by passing 
it as <param-name>=<param-value>, just like the set of well-known 
parameters. 


WARNING: Vendors and applications MUST NOT include sensitive 
information (such as authorization tokens) in a URI. Other means of 
authorization, authentication, and identification ought to be used. 
Also see the security discussion below about properties that might be 
duplicated as JMS message properties. 
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Encoding Considerations 


The "jms" URI scheme distinguishes between <unreserved> characters 
and <pct-encoded> characters, as defined in [RFC3986]. Apart from 
these encoding considerations, the characters "?" and "&" MUST be 
encoded when they appear within the <jms-dest> particle (for example, 
a JNDI name) or in query parameters. The character ":" SHOULD be 
escaped when appearing in the <jms-dest> portion of the syntax. 


Conversions to and from Internationalized Resource Identifiers (IRIs) 
follow the rules of RFC 3987, Sections 3.1 and 3.2. As per 

Sections 1.2-c. and 6.4 of [RFC3987], all parts of the JMS URI MUST 
use the UTF-8 encoding when converting to and from the IRI format. 


Applications/Protocols That Use the JMS URI 


A variety of vendors provide implementations of the JMS Service 
Provider Interface (SPI). These products interoperate at the API 
level, in the Java programming language. 


Some vendors have provided additional products that interoperate with 
their own SPI implementations. These extensions might also be able 
to make use of this URI scheme. 


The vendors working on this URI scheme are also working ona 
specification for carrying SOAP messages over their respective 
implementations of JMS [SOAP-JMS]. In addition, the Service 
Component Architecture Bindings technical committee (TC) [SCA-TC] at 
OASIS employs the "jms" URI scheme to identify JMS Destinations in 
[SCA-JMS] . 


Interoperability Considerations 


This "jms" URI scheme focuses on identifying a JMS Destination 
object, and some characteristics of communication using that 
Destination, and specifically excludes any notion of describing how 
JMS itself is implemented and how it delivers messages. As a 
consequence of this focus, interoperability concerns are limited to 
how implementations obtain and use a Destination object. 


This scheme definition describes three variants for obtaining a 
Destination. These variants achieve their aims with the use of JNDI 
and JMS APIs, with no new APIs or protocols defined here. Asa 
consequence of using JNDI and JMS, interoperability concerns might 
arise if implementations do not conform to the specifications for 
those APIs. Further, the use of Java, and JNDI in particular, means 
that the configuration of the execution environment and the use of 
Java ClassLoaders can affect the interpretation of any given URI. 
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8. 


Consumers of these URIs are urged to consider the scope and 
consistency of the environment across which these URIs will be 
shared. 


As described in Section 4, others can define additional variants, 
which provide the means to describe how to look up JMS Destination 


objects in a manner specific to some environment. For any new 
variant, the shared parameters defined in Section 4.1 MUST have the 
same meaning in that variant as they do here. That way, tools and 


people can safely copy these parameters between environments. Note 
that while additional variants might seem more flexible, employing 
variants not defined here might make it more difficult to switch to 
an alternate JMS provider. 


Security Considerations 


Section 7 of [RFC3986] identifies some of the security concerns that 
ought to be addressed by this specification. 


1. Reliability and Consistency 


This specification identifies only the variant (<jms-variant>) and 
variant-specific details (<jms-dest>) as an essential part of the 
URI. For reliability and consistency purposes, these variants are 
the only part that can reasonably be expected to be stable. Other 
optional JMS configuration and message properties indicated as URI 
parameters, like "timeToLive", can reasonably be determined by the 
sender of a message, without affecting the recipient. Insofar as a 
recipient might wish to dictate certain parameters, such as the 
"JjJndiConnectionFactoryName", those parameters can be specified. 


-2. Malicious Construction 


-2.1. Recipient Concerns 


A malicious consumer of a service using a JMS URI could send, as part 
of a JMS message, a URI with a parameter such as "timeToLive" with a 
value specified in the URI that differs from the corresponding JMS 
message property ("JMSExpiration" header field, in this example). In 
the case of such messages with such URIs, recipients are strongly 
cautioned to avoid applying processing logic based on particular URI 
parameters. Discrepancies in the message could be used to exploit 
differences in behavior between the selectors that a JMS-based 
application might use to affect which messages it sees, and the 
processing of the rest of the application. As defined in this 
document, the parameters of concern include: 


Phillips, et al. Informational [Page 14] 


RFC 6167 jms" URI Scheme April 2011 


deliveryMode 
timeToLive 


priority 


Message senders are strongly urged to remove from the URI extra 
parameters like the above in environments where the data will be 
redundant with information specified elsewhere in the JMS message. 


Any use of additional parameters, either as a part of a definition of 
a new variant or for more general use, SHOULD also specify whether 
those parameters ought to be removed by a sender as specified here. 
If a recipient is aware of the "jms" URI scheme, and it receives a 
message containing a JMS URI, it MUST ignore or discard parameters 
that it does not recognize. 


8.2.2. Sender Concerns 


A third party could intercept and replace a URI containing any of the 
JMS/JNDI configuration parameters, such as 
"JndiConnectionFactoryName", "jndiInitialContextFactory", or 
"j3ndiURL". As these parameters can affect how an implementation 
establishes an initial connection, such parameters could be used as a 
means to subvert communications. This could possibly result in 
re-routing communications to third parties, who could then monitor 
sent messages. Clients SHOULD NOT use these URI parameters unless 
assured of their validity in trusted environments. 


8.3. Back-End Transcoding 


This specification, in using the URI specification and building 
around the JMS specification, has no particular transcoding issues. 
Any such issues are problems with the underlying implementation of 
Java and the Java Messaging Service being employed. 


8.4. Semantic Attacks 


A possible semantic attack on the "jndi" variant could be 
accomplished by replacing characters of the JMS URI from one language 
with equivalent-looking characters from another language, known as an 
"Internationalized Domain Name (IDN) homograph attack" [HOMOGRAPH]. 
This kind of attack could occur in a variety of ways. For example, 
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8. 


9. 


9. 


if an environment allows for the automatic registration of JNDI 
Destination names, a malicious actor could register and then 
publicize an alternate of an existing Destination name. Such an 
environment ought to prevent the use of homograph equivalents, 
perhaps by restricting allowed characters, so that clients do not 
accidentally send their requests to unintended Destinations. 


The "queue" and "topic" variants are subject to the same concerns as 
the "jndi" variant. In addition, because the Destination names are 
vendor defined, URIs employing these two variants might employ 
special characters that significantly change the meaning of the URI. 
It is possible that the introduction of a single character -- 
difficult for a human to notice -- might dramatically change the 
intended meaning of a URI. In situations where this might be an 
issue, users of this URI are urged to strongly consider the "jndi" 
variant instead. 
5. Other Security Concerns 

This specification does not define or anticipate any use for IP 
addresses as part of the URI, so no issues around IP addresses, rare 
or otherwise, are raised by this specification. 


This specification does not define any characteristics of a "jms" 
scheme URI that contain sensitive information. 


IANA Considerations 
1. URI Scheme Registration 
IANA registered the Java Message Service URI scheme described in this 
document, according to the following scheme registration request, 
using the template from [RFC4395]: 
o URI scheme name: jms 
o Status: Provisional 
o URI scheme syntax: See Section 3 
o URI scheme semantics: See Section 4 


o Encoding considerations: See Section 5 


o Applications/protocols that use this URI scheme name: See 
Section 6 


o Interoperability considerations: See Section 7 
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o Security considerations: See Section 8 
o Contact: See the Authors’ Addresses section 
o References: See the References section 

9.2. "jms" URI Scheme Registries 


Per this URI scheme, IANA has created a registry for possible 
"variants". IANA can reject obviously bogus registrations. 


9.2.1. JMS URI Variants 


This registry provides a listing of "jms" URI scheme variants. 
Variant names beginning with "vnd." are reserved for vendor 
extensions. Such variants should follow a pattern of 
vnd.<vendorname>.<label>. The <vendorname> corresponds to the 
iana-vendor-tag production from [RFC6075], and vendor.<vendorname> 
must already be registered in the Application Configuration Access 
Protocol (ACAP) Vendor Subtree. The <label> is chosen by said 
vendor. 


All variant names are to be registered on a first come, first served 
basis. 


Variants must conform to the "jms-variant" production above. Since 
variants occur in URIs, they ought to be short, and MUST NOT be more 


than forty characters in length. 


This document defines the "jndi", "queue", and "topic" variants 
initially included in the registry. 


9.2.2. "jms" URI Scheme Variant Registration Template 


This template describes the fields that must be present to register a 
new variant for use in a JMS URI. 


To: iana@iana.org 
Subject: Registration of JMS URI variant name 


JMS URI variant name: Variants must conform to the "jms-variant" 
production above. Since variants occur in URIs, they ought to be 


short, and MUST NOT be more than forty characters in length. 


Description: A description of the purpose of the variant being 
registered. 
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Contact Information: Name(s) and email address(es) to contact for 
more information about this registration. 


Description URL: If available, a URL for a document describing the 
details of how the variant works. 


Comments: Any comments the requester thinks are relevant to this 
request. 


Change Controller: Contact information for the person who controls 
further changes to this variant definition. 


9.2.3. Change Control 


Once a JMS URI variant registration has been published by IANA, the 
change controller can request a change to its definition. The change 
request follows the same procedure as the registration request. 


The change controller of a JMS URI variant can pass responsibility 
for the JMS URI variant to another person or agency by informing 
IANA; this can be done without discussion or review. 


JMS URI variant registrations MUST NOT be deleted; mechanisms that 
are no longer believed appropriate for use can be marked as obsolete 
in the Comment field. 


In exceptional circumstances, the IESG can reassign responsibility 
for a JMS URI variant. 


The IESG is considered to be the owner of all JMS URI variants that 
are on the IETF Standards Track. 
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